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INFORMATION SERVICE LAYER 



CROSS-REFERENCE TO RELATED APPLICATIONS 

[0001] This application is related to U.S. Patent Application Serial No. 

, entitled "System For Processing Data Retrieved From An Infonmation 

Sen/ice Layer", and U.S. Patent Application Serial No. , entitled 

"Centralized Monitoring and Eariy Warning Operations Console", filed concun-ently and 

incorporated herein by reference for all purposes. 

STATEMENT REGARDING FEDERALLY SPONSORED 
RESEARCH OR DEVELOPMENT 

[0002] Not applicable. 

REFERENCE TO A MICROFICHE APPENDIX 
[0003] Not applicable. 

FIELD OF THE INVENTION 
[0004] The field of the present invention includes computer software. More particulariy, 
embodiments of the present invention are concemed with accessing enterprise computer 
programs to extract data and to issue commands. 

BACKGROUND OF THE INVENTION 
[0005] In a large corporate enterprise, management and operations infonnation may be 
spread across multiple unrelated computer systems. It may be Infomnation from different 
computer programs (hereinafter referred to as applications) - for example, an operations 
control application supplying production or service delivery infonnation and an accounting 
application supplying cost infonnation - is needed to assess the perfonnance of the 
enterprise at a high level. The infonnation may be useful In calculating costs as a Unction 
of the level of pert'onnance rather than just the cost of operating. These and other 
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calculations may be valuable to managers and executives making business decisions for 
the enterprise. But if the different applications are incompatible one with another this 
infomiation may not be available or may not be available in a timely fashion or may not be 
available in a cost effective manner 

[0006] The enterprise may have two or more different mainframe computer systems, 
several UNIX computer systems, and many desktop computer systems which support 
different enterprise business applications. The different mainframe computer systems may 
be located at different physical locations and may be under the control of different units of 
the company. Each computer system may Itself comprise a complex of applications, data, 
and databases. Some of the applications may be developed by the enterprise, while other 
applications may be developed by third parties. Some applications and systems may be 
very old. 

[0007] The interface which may be used to extract infomiation or data from one 
application may not work for any other application. The data fomiat produced by one 
application may not be compatible with the data fomiat produced by any other application. 
Attempting to communicate among different computer systems poses additional problems. 
The different operating systems on different computer systems may not support common 
communication mechanisms. For example, a UNIX computer system may support socket 
communications between independent machines while the mainframe computer system 
may not support socket communications. 

[0008] To verify the successful progress of a large application, enterprise personnel 
may access data in files with a text editor and cut-and-paste this information directly into a 
commercial spreadsheet application in order to perfonn calculations on the progress of the 
application. This is a laborious and en^or prone process. If the process only fails 1 % of the 
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time - perhaps once every three months - this manual approach may be considered 
inefficient. 

[0009] When an enterprise depends upon its deployed resources to support its 
production it may be desirable to be able to predict when growth will exhaust the deployed 
resources so additional resources can be deployed before growth is stalled. 

SUMMARY OF THE INVENTION 
[00101 The present embodiment provides an infomation service layer for data retrieval. 
The information service layer Includes a control system having a registry and operable to 
receive a request for data from a requestor, the request including a source identifier and a 
data identifier; a client service operable to register with the control system and receive the 
request for data, the client service further operable to communicate a requested data 
related to the data identifier to the requestor; and a retrieval service operable to utilize at 
least a portion of the source identifier to retrieve the requested data related to the data 
identifier and communicate the requested data to the client service. 
[0011] In one embodiment a method of obtaining data for a client utilizing an 
information service layer is provided comprising building a request for data based on input 
of desired data by a requestor, the request for data Including an extensible markup 
language tag; transmitting the request from the requestor to a service layer operable to 
control data services; registering a client service for servicing data requests in a registry of 
the service layer; notifying the service layer by the requestor; establishing communication 
between the requestor and the client service; calling, by the client service utilizing at least a 
portion of the request for data, a retrieval service operable to obtain data; obtaining a 
requested data based on the request for data; transmitting the requested data from the 
retrieval service to the client service; transmitting the requested data from the client service 
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to the requestor; and noting in the registry of the service layer an idle state of the client 
service. 

[0012] These and other features and advantages will be more clearly understood from 
the following detailed description taken in conjunction with the accompanying drawings and 
claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0013] For a more complete understanding of the presentation and the advantages 
thereof, reference is now made to the following brief description, taken in connection with 
the accompanying drawings and detailed description, wherein like reference numerals 
represent like parts. 

[0014] Figure 1 is a block diagram, according to one embodiment, of the functional 

components of an information service layer of the present disclosure. 

[0015] Figure 2 is a block diagram, according to another embodiment, of the functional 

components of the information service layer of the present disclosure. 

[0016] Figure 3 depicts an exemplary infonrnation service layer request-response 

message sequence. 

[0017] Figure 4 depicts an example of an infonmation service layer acting in the role of a 
proxy requestor. 

[0018] Figure 5 is a block diagram, according to one embodiment, of the functional 
components of an infonnation command layer of the present disclosure. 
[0019] Figure 6 is a block diagram, according to one embodiment, of a centralized 
application monitor/eariy warning operations console system of the present disclosure. 
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[0020] Figure 7 is a block diagram, according to anotlier embodiment, illustrating the 
functional components of the centralized application monitor/early warning operations 
console system of the present disclosure. 

[0021] Figure 8 illustrates one exemplary cooperative configuration of the information 

service layer, infomiation command layer, the centralized application monitor/early waming 

operations console system, and a remote desktop user interface. 

[0022] Figure 9 illustrates an exemplary general purpose computer system suitable for 

implementing the several embodiments of the information service layer, the information 

command layer, and the centralized application monitor/early waming operations console 

system. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
[0023] It Should be understood at the outset that although an exemplary implementation 
of one embodiment of the present invention is illustrated below, the present system may be 
implemented using any number of techniques, whether currently known or in existence. 
The present disclosure should in no way be limited to the exemplary implementations, 
drawings, and techniques illustrated below, including the exemplary design and 
Implementation illustrated and described herein, but may be modified within the scope of 
the appended claims along with their full scope of equivalents. 

[0024] Turning now to Figure 1 an information service layer (ISL) 10 is depicted. The 
ISL 10 enables searching for and obtaining data as well as invoking commands across 
disparate computer systems or computer platfomis in a manner which makes the 
differences of these systems and platforms transparent to the user of the ISL 10. Note that 
unlabeled drawing lines between labeled elements in Figure 1 and subsequent figures 
indicate that the labeled elements may be in communication. The communication may be 
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unidirectional or bidirectional. The communication may be supported by executing function 
calls, by employing inter-process communication mechanisms, by electrical conductors, or 
other means. 

[0025J A mediator 12 receives requests from a requestor 14 for information or data 
stored in a computer system or for the computer system to execute commands. The 
mediator 12 may also be referred to as a control system. The requestor 14 may also be 
referred to as a request builder The requestor 14 may execute on, for example, a desktop 
computer, a UNIX computer system, or a mainframe computer system different from the 
computer system on which the ISL 10 executes. The requestor 14 may execute, in some 
embodiments, on the computer system on which the ISL 10 executes. The mediator 12 
delegates responsibility to handle the request from the requestor 14 to a client service 16. 
[0026] The client service 16 is an application which reads through the request sent by 
the requestor 14 and acts to satisfy the request. 

[0027] In some embodiments the initiating communication between the requestor 14 
and the mediator 12 does not contain a request but merely a handshake to establish 
communications. The mediator 12 may hand off completion of the communications 
handshake to the client service 16, The client service 16 establishes communications with 
the requestor 14 and receives the request directly from the requestor 14 without being 
routed through the mediator 12. 

[0028] The client service 16 communicates with a retrieval service 18 which is an 
application that interacts with a database 22 to access and collect the requested data or to 
issue commands to the database 22. The retrieval service 18 returns the requested data 
to the client service 16. The client sen/ice 16 returns the requested data to the mediator 
12. The mediator 12 returns the requested data to the requestor 14. 
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[0029] While the embodiment depicted in Figure 1 shows the retrieval service 18 
retrieving data from a database 22, in other embodiments the retrieval service 18 may 
retrieve data from an active computer application, from a file system, or from some other 
source. While only one requestor 14 is depicted, the mediator 12 is intended to accept 
requests from multiple requestors 14. In some embodiments the mediator 12 may hand-off 
communication information to the client service 16 enabling the client service 16 to 
communicate directly to the requestor 14 and to retum the requested infomiatlon or data 
directly to the requestor 14 without the intervention of the mediator 12. 
[0030] The ISL 10 and its components may execute on a general purpose computer 
system. General purpose computer systems are discussed in more detail hereinafter. The 
various components of the ISL 10 may execute on the same computer or they may 
execute on different and separate computers. 

[0031] Turning now to Figure 2 another embodiment of the ISL 10 is depicted. In this 
embodiment the mediator 12 includes a listening port 13 to which the requestor 14 sends 
its request. The listening port 13 is operative to receive an unscheduled communication 
from a requestor 14. 

[0032] Five Instantiations of the client service 16 - client service #1 16a, client service 
#2 16b, client service #3 16c, client service #4 16d, and client service #5 16e - are 
illustrated as ainning. Each of the client services 16a-e is an instantiation of the same 
application which reads through the request sent by the requestor 14 and acts to satisfy the 
request. In some embodiments more than five or less than five instantiations of the client 
service 16 may be running. 

[0033] The retrieval service 18 depicted in Figure 1, in the embodiment depicted in 
Figure 2 has been further particularized to support specific applications or computer 
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systems. All retrieval services 18, however, are endowed with internal logic to accept and 
properly respond to requests for data and command invocations embedded in the request 
sent by the requestor 14. 

[0034] A source archive (SAR) service 18a may provide access to printout files 22. 
Printout files 22 may be generated by applications running on mainframe computer 
systems and capture information about the processing conducted by the applications. This 
infonnation may be stored in text files in a format which is not readily accessible to human 
readers. The files may be continuously appended to as applications execute. The files 
may be closed when they achieve a maximum file size and a new file opened for writing. 
The files may be closed when a specified length of time passes and a new file opened for 
writing. Multiple instantiations - SAR service #1 18a-1, SAR service #2 18a-2, and SAR 
service #3 18a-3 - of the same SAR service 18a application are illustrated as njnning. In 
some embodiments more or fewer instantiations of the SAR service 18a may be running. 
[0035] A problem management system (PMS) service 18b may provide access to a 
RMS 23. Multiple instantiations - PMS service 18b-1, PMS service 18b-2, and PMS 
service 18b-3 - of the same PMS service 18b application are illustrated as running. In 
some embodiments more or fewer instantiations of the PMS service 18b may be running. 
A PMS 23 may hold trouble tickets or other artifacts recording the details of a reported 
problem. The PMS 23 may support updating during the life of the trouble tickets as the 
reported problem is worked on over time and may retain trouble tickets for resolved 
problems for historical purposes. 

[0036] A scheduler service 18c may provide access to a scheduler 26. Multiple 
instantiations - scheduler service #1 18c-1, scheduler service #2 18c-2, and scheduler 
service #3 18c-3 - of the same scheduler service 18c application are illustrated as running. 
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In some embodiments more or fewer instantiations of the scheduler service 18c may be 
running. In some embodiments the scheduler may be a CA-7 scheduler from Computer 
Associates. In one embodiment, access to this scheduling system might provide detailed 
infomriation related to the sequence of tasks or jobs that have already or are planned to be 
executed. This information could be used In conjunction with job execution infomriation 
fonn the source archive and problem management queries to provide current state, 
forecast completion, or assist in either resolving an existing failure or predicting a pending 
one. 

[0037] ISL 10 Is intended to accept concun^ent requests from multiple requestors 14. 
The purpose of ISL 10 executing multiple instantiations of client service 16 and multiple 
instantiations of retrieval services 18 is to reduce the chance that when the requestor 14 
sends a request that the requestor 14 will have to wait or be denied service and have to 
resubmit a request at a later time because the designated retrieval service 18 is busy. If 
the mediator 12 finds there is no idle client service 16 to handle a request, the mediator 12 
brings an additional Instantiation of client service 16 into operation. In some embodiments 
if there are no idle retrieval services 18a, 18b, or 18c available to handle a request, the 
mediator 12 may bring an additional instantiation of the appropriate retrieval service into 
operation. 

[0038] For other systems or applications additional retrieval services 18 may be needed 
to provide access to those systems or applications. Access to systems or applications may 
include both retrieval of data and issuing commands. An additional retrieval service 18 
may provide access to a code control system (a code control system is a computer 
program which supports managing code or software changes). 
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[0039] A register 24 contains information about each instantiation of the client service 
16 and each instantiation of the retrieval services 18a-c. The information stored in the 
register 24 is employed to pass work to and control the interworking of the client services 
16 or retrieval services18a-c. This information may include an indication whether the 
represented service is busy or idle and an indication of what action to take on completion of 
a task (referred to below as action-on-completion information). Each of the instantiations of 
client services 16 and retrieval services 18a-c create entries in the register 24 during 
initialization. In one embodiment the register 24 entries may include a process id (PID) 
identifying the service associated with the entry and a signal number on which the 
operating system will reawaken the idle or sleeping service. 

[0040] An administrative services component 28 supports starting and stopping the 
various services. The administrative services component 28 may support bringing new 
retrieval services 18a-c into operation which had not previously been part of the ISL 10. 
[0041] Turning now to Figure 3 an exemplary request-response cycle of the ISL 10 is 
depicted. Note, however, that the present disclosure should not be limited by this 
exemplary request-response cycle. The requestor 14 sends a communicationRequest 
message 50 to the mediator 12. In some embodiments the communication with the 
requestor 14 may be via a socket communication mechanism. The requestor 14 may 
address its initiating communicationRequest message 50 to the known computer system 
and the known protocol port of the listening port 13. In some embodiments the operating 
system may not support the socket communication mechanism, and in this case another 
equivalent communication mechanism may be employed. 

[0042] To Identify an idle client service 16 instantiation, the mediator 12 sends a 
clientServiceLookup message 52 to the register 24. The register 24 searches its contents, 
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finds an idle client service 16 instantiation, and sends a clientServiceFound message 54 to 
the mediator 12 which identifies the idle client service 16 instantiation. The 
ClientServiceFound message 54 may contain a process identifier (RID) of the idle client 
service 16 instantiation and the signal by which the mediator 12 may cause the operating 
system to put the idle client service 16 instantiation into operation. In action 56 the 
mediator 12 activates the appropriate signal to cause the client service 16 instantiation to 
awake. In some embodiments the register 24 may not be intelligent and the mediator 12 
may read through each entry of the register 24 using successive read requests until the 
mediator 12 reads an entry which is associated with an idle client service 16 instantiation. 
In some embodiments the operating system may not support signals, and in this case 
another equivalent mechanism to bring an idle client service 16 instantiation into operation 
may be employed. 

[0043] The client sen^ice 16 instantiation awakes at label 58. The client service 16 
instantiation sends a clientServiceBusy message 60 to the register 24 causing the register 
24 entry associated with the client service 16 instantiation to indicate busy status. The 
mediator 12 sends a socketHandoff message 62 identifying the pertinent communications 
link infomnation for requestor 14 to the client service 16 instantiation. The mediator 12 
frees the listening port 13 to listen for other new requests. The client service 16 
instantiation sends a socketReady message 64 to the requestor 14 establishing a socket 
communication link with the requestor 14. 

[0044] The requestor 14 sends a requestDocument message 66 over the socket link to 
the client service 16 instantiation. The requestDocument message 66 contains a 
document describing the infomiation or data request. In some embodiments the document 
may be in extensible markup language (XML) fomiat. XML is preferred because it 
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provides for the integration and collation of any data and infomnation regardless of storage 
environment or document type, because it enables data interchange and is platfonn and 
application independent, because it supports customization and personalization of 
infomnation, and because it is extensible. While XML forniat is preferred for extensibility 
and its ability to describe data through tags, the relationship between data elements 
through the nesting of this tag, and requested criteria and functions through the content 
encapsulated by tags, in other embodiments an altemative document fonnat may be 
employed. The term 'document' is conventional when referring to XML, HTML, or other tag- 
based mari<up languages and refers to a sequence of tags and enclosed data. In other 
embodiments some format other than a document fomnat may be employed to send the 
request. In some embodiments the request is passed to the mediator 12, and the mediator 
12 forwards the request to the client service 16 instantiation. 

[0045] The requested XML document embeds a designation of both the computer 
system on which to locate the data and the retrieval service 18 which must be employed to 
retrieve the data specified in the request XML document. If the designated computer 
system is the local computer system, in action 68 the client service 16 writes the request 
XML document into a file and notes the designated retrieval service 18. 
[0046] The client service 16 instantiation sends a sarServiceLookup message 70 to the 
register 24 (this example request-response sequence assumes that a SAR data access is 
needed, and in the case that the request is for a different data access, an alternative 
service lookup would occur). The register 24 searches its contents, finds an idle SAR 
service 18a instantiation, and sends a sarServiceFound message 72 to the client service 
16 instantiation which identifies the idle SAR service 18a instantiation. The 
sarServiceFound message 72 may contain the signal by which the client service 16 
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instantiation may cause the operating system to put the idle SAR service 18a instantiation 
into operation. 

[0047] The client service 16 instantiation sends serviceUpdate message 74 to the 
register 24 which causes the entry associated with the idle SAR service 18a instantiation to 
be updated with the name of the request document file written by the client service 16 
instantiation and to be updated with the signal associated with the client service 16 
instantiation wake-up. In action 76 the client service 16 instantiation activates the 
appropriate signal to cause the SAR service 18a instantiation to awake. The client service 
16 instantiation then puts itself to sleep at label 78. 

[0048] In some embodiments the client sen/ice 16 instantiation may save infomiation 
about the progress the client service 16 instantiation has made in handling the requestor 
14 request, write to the register 24 entry associated with the client service 16 instantiation 
an idle indication, and then put Itself to sleep. In such an embodiment, the SAR service 
18a instantiation would signal to any idle client service 16 instantiation when returning data. 
This client service 16 instantiation - perhaps a different client service instantiation than the 
one which sent the signal in action 76 which woke up the SAR service 18a instantiation - 
then accesses the saved information which indicates the progress made in handling the 
requestor 14 request. In some embodiments the operating system may not support 
signals: In this case another equivalent mechanism to bring an idle SAR service 18a 
instantiation into operation may be employed. 

[0049] The SAR service 18a instantiation is awakened by the operating system at label 
80. The SAR service 18a instantiation sends a sarServiceBusy message 82 to ttie register 
24 causing the register 24 entry associated with the SAR service 18a Instantiation to 
indicate busy status. The SAR service 18a instantiation sends a getSAREntry message 84 
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to the register 24. The register 24 returns a putSAREntry message 86 to the SAR service 
18a instantiation which contains information including the name of the request document 
file and the action-on-completion for the SAR service 18a instantiation. 
[0050] In action 88 the SAR service 18a instantiation reads the request document file or 
files. In action 90 the SAR service 18a instantiation follows the instructions embedded in 
the request document file to access data out of the printout files 22. In some embodiments 
the client service 16 instantiation may send the request document directly to the SAR 
service 18a instantiation as a message. Other communications means and pathways may 
be employed for access to the retrieval services 18. 

[0051] In action 92 the SAR service 18a instantiation follows the instructions embedded 
in the request document file to write the accessed data into a response document file. The 
name of the response document file is deterministically related to the name of the request 
document file. For example, if the request document file name is *Request.xml the 
response document file name may be *Response.xml. In some embodiments the 
response document may be in XML fonnat. In other embodiments an altemative document 
format may be employed. In some embodiments actions 88 and 90 may be combined and 
not separate steps. In some embodiments actions 90 and 92 may be combined and not 
separate steps. In some embodiments actions 88, 90, and 92 may be combined and not 
separate steps. In some embodiments the response document may be returned to the 
client service 16 instantiation in a message from the SAR service 18a instantiation to the 
client service 16 instantiation. 

[0052] In action 94 the SAR service 18a instantiation activates the appropriate signal to 
cause the client service 16 instantiation to awake. The SAR service 18a instantiation 
sends a sarServiceldle message 96 to the register 24 causing the register 24 entry 
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associated with the SAR service 18a instantiation to indicate idle status. The SAR service 
18a instantiation then puts itself to sleep at label 98. 

[0053] The client service 16 instantiation is awakened by the operating system at label 
100. In action 102 the client service 16 instantiation reads the response document file. 
The client service 16 instantiation sends a responseDocument message 104 over the 
socket link to the requestor 14 containing the response document describing the requested 
infonnation or data and closes the socket communication link. In some embodiments the 
document may be in XML format, and in such embodiments the client service 16 
instantiations and retrieval service 18a-c instantiations are XML operable. In other 
embodiments an alternative document format may be employed, and in such embodiments 
the client service 16 instantiations and retrieval service 18a-c instantiations are operable to 
work with this alternative document format. In some embodiments the client sen/ice 16 
instantiation may delete the request document file and the response document file after 
closing the socket communication link to the requestor 14. 

[0054] The client service 16 instantiation sends a clientSen^iceldle message 106 to the 
register 24 causing the register 24 entry associated with the client service 16 instantiation 
to indicate idle status. The client service 16 instantiation then puts itself to sleep at label 
108, completing the request-response cycle. In some requestor 14 requestDocument 
messages 66 multiple retrieval services 18 may be designated. In this case the client 
service 16 instantiation may conduct multiple retrieval sen/ice 18 sessions similar to the 
sequence 80 through 98 with a series of retrieval services 18. 

[0055] If the computer system designated in the request XML document sent by the 
requestor 14 to the client service 16 is not the local computer system, the client service 16 
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instantiation in the present embodiment acts as a proxy requestor and forwards the request 
on to the ISL 10 on the remote designated computer system. 

[0056] Refem'ng now to Figure 4 a local ISL 10 is shown fonA/arding a request from a 
requestor to a remote ISL 10. In this example the requestor 14 is Illustrated as running on 
the same computer system 120 as the local ISL 10, though the requestor 14 may be 
running on some other computer system. The information which the requestor 14 requests 
Is located on a remote computer system 122 which supports its own ISL 10. 
[0057] The client service 16a instantiation on the local computer system 120 may 
communicate with the local mediator 12 to obtain communication infonnation to enable the 
client service 16 to communicate with the ISL 10 on the remote designated computer 
system. The local mediator 12 may look this infomnation up in a configuration file. In some 
embodiments the infonnation in the configuration file may map the name of a designated 
computer system to the intemet protocol (IP) address of the remote computer system and 
the protocol port number of the listening port for the ISL 10 on that remote computer 
system. In some embodiments the protocol port number of the listening port may be hard 
coded and common among all deployed ISLs 10, and in this case there may be no need to 
store the protocol port number of the listening port in the configuration file. If 
communication mechanisms other than sockets are employed, other communications 
Infonnation may be stored in the configuration file such as universal reference locator 
(URL) or other. 

[0058] The client service 16a instantiation may be said to act as a proxy requestor. 
That is to say, from the viewpoint of the ISL 10 on the remote computer system 122 the 
client service 16a instantiation on the local computer system 120 appears to be a requestor 
14. The client service 16a instantiation on the local computer system 120 follows the 
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request protocol as a normal requestor 14 would follow the request protocol. In some 
embodiments the local client service 16a instantiation may register with the remote register 
24 and interact directly with the appropriate remote retrieval service 18a-c on the remote 
computer system 122. 

[0059] While not depicted in Figure 4, it is possible for the ISL 10 operating on the 
remote computer system 122 to itself act as a proxy requestor and fonrt/ard the original 
request on to yet a further removed ISL 10 not shown. There is no functional limit to the 
depth of such a series of proxy requests. 

[0060] The example description of a request-response cycle above is only exemplary 
and is not intended to constrain or limit the disclosure or claims in any way. The names of 
the messages are arisitrary and In some embodiments may be differently named and 
contain different infomriation. The example described a request for data, but it may have 
been a request to command some action or series of actions to be taken by an application. 
[0061] Any instructions or logic embedded in an XML document are viewed as data 
from the perspective of an XML parser. The meaning of the data embedded In an XML 
document is constructed by the applications which employ the XML document. An 
example XML document embedding an Infomiation or data request for use with the ISL 10 
is presented below. This example will be followed by a line-by-line description of the 
meaning constructed upon the XML data contained within the example XML document. 

1 : <SYSID><NAME>BILLING_SERVER</NAME> 

2: <SAR> 

3: <DBASE><NAME>BILLSYS.JCL.DB7</NAME></DBASE> 
4: <PARSE> 

5: <ID>PIP*</ID><DATA>02/10/03:02/20/03</DATA> 
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6: <FIND><NEXT>CZT1 765</NEXT></FIND> 

7: <TAGNAME><NAME>J0BNAME</NAME><LENGTH><0FFSET>8</0FFSET> 
</TAGNAME> 

8: <TAGNAME><NAME>START</NAME><LENGTH>8</LENGTH> 

<P0S>2</P0S></TAGNAME> 
9: <FIND><NEXT>CZT1 775</NEXT><LENGTH>7</LENGTH></TAGNAME> 
1 0: <TAGNAME><NAME>ENDED</NAME><LENGTH>8</LENGTH> 

<P0S>2</P0S></TAGNAME> 
1 1 : <FIND><PREV>-JOBNAME</PREV></FIND> 
12: <UNTIL> 

1 3: <ST0PAT><VALUE>CZT1 775<A/ALUE><LENGTH>7</LENGTH> 

<LINE>1</LINE><^AGNAME> 
14: <SKIPUNTIL><VALUE>-</VALUE><LENGTH>1 </LENGTH></SKIPUNTIL> 
1 5: <TAGNAME><NAME>STEPSTART</NAME><LENGTH>8</LENGTH> 

<0FFSET>-1 9</0FFSET><n"AGNAME> 
1 6: <TAGNAME><NAME>STEP</NAME><LENGTH>8</LENGTH> 

<TAGNAME> 

1 7: <TAGNAME><NAME>PR0C</NAME><LENGTH>8</LENGTH> 

<0FFSET>1 9</0FFSET></TAGNAME> 
1 8: <TAGNAME><NAME>RC</NAME><LENGTH>5</LENGTH> 

<OFFSET>28</OFFSET><n'AGNAME> 
1 9: <TAGNAME><NAME>EXCP</NAME><LENGTH>6</LENGTH> 

<OFFSET>34</OFFSET><n'AGNAME> 
20: <TAGNAME><NAME>CPU</NAME><LENGTH>6</LENGTH> 
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<OFFSET>42</OFFSET></TAGNAME> 
21 : <TAGNAME><NAME>ELAPSED</NAME><LENGTH>6</LENGTH> 

<OFFSET>56</OFFSET><n'AGNAME> 
22: </UNTIL> 
23: </PARSE> 
24: </SAR> 
25: </SYSID> 

Line 1: Route request to the ISL 10 on the BILLING_SYSTEM computer system. 

Line 2: Use the SAR service 18a. 

Line 3: Open the BILLSYS.JCL.DB7 SAR database. 

Line 4: Parse all data using the following commands. 

Line 5: Locate all reports that begin with PIP that were created on 02/10/03 

through 02/20/03 
Line 6: Search the report for "CZT1765". 

Line 7: Skip over 8 characters from the position that the text was found and 

grab the next 8 characters. Build an output tag called JOBNAME 
and use it to encapsulate the located value in the output 
XML document file. 

Line 8: Grab the 8 characters beginning at position 2 on the line that the 
FIND is pointing to and create a tag called START and use 
it to encapsulate the located value in the output XML 
document file. 

Line 9: Search further down the report for "CZT1775". 

Line 10: Grab the 8 characters beginning at position 2 on the line that the FIND 
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is pointing to and create a tag called ENDED and use it to 
encapsulate the located value in the output XML document file. 

Line 1 1 : Search backwards through the report for "JOBNAME". 

Line 12: Begin looping through the report. 

Line 13: If the value "CZT1775" is found then stop the loop, otherwise skip 

down to the next line in the report. 
Line 14: Check for a "-" and skip any line that does not have that character 

in the same position as the found text. 
Line 1 5: Create a tag in the output XML document file called STEPSTART 

encapsulating the 8 characters at an offset of 19 characters 

before the found text position. 
Line 16: Create a tag in the output XML document file called STEP encapsulating 

the 8 characters at an offset of 10 from the found text position. 
Line 17: Create a tag in the output XML document file called PROC encapsulating 

the 8 characters at an offset of 19 from the found text 

position. 

Line 18: Create a tag in the output XML document file called RC encapsulating 

the 5 characters at an offset of 28 from the found text position. 
Line 19: Create a tag in the output XML document file called EXCP encapsulating 

the 6 characters at an offset of 34 from the found text position. 
Line 20: Create a tag in the output XML document file called CPU encapsulating the 

6 characters at an offset of 42 from the found text position. 
Line 21 : Create a tag in the output XML document file called ELAPSED 

encapsulating the 6 characters at an offset of 56 from the found 
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text position. 

Line 22: End of commands within this loop. 

Line 23: End of parsing commands. 

Line 24: End of commands for the SAR service. 

Line 25: End of requests for this system. 
[0062] An example output XML document embedding a response to the 
information or data request is presented below. 

<RESULTS> 

<SYSOUT> 

<SYSOUT_ID>XYZ280</SYSOUT_ID><SEQ_KEY>XYZ280</SEQ_KEY> 
<JOB>JOB65241</JOB><GEN>7982</GEN> 
<SSEQNO>7823</SSEQNO><ARCDT>01/20/03</ARCDT> 
<ARCTM>13:18:15</ARCTM><PRTDT>00/00/00</PRTDT> 
<LINES> 5373</LINES><PAGES 37</PAGES> 
<BLKS> 31</BLKS><XC0DE> </XCODE> 
<TAPSEQ>4450<n"APSEQ> 

<JOBNAME>XYZ280</JOBNAME> 

<START>1 2.37.5</START> 

<ENDED>1 2.43.52</ENDED> 

<ROW> 

<STEPSTART>1 2.37.52</STEPSTART> 
<STEP>KEQ873FGW</STEP> 
<PROC>FGW@20</PROC> 
<RC> 00</RC> 
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<EXCP> 22</EXCP> 
<CPU> .00</CPU> 
<ELAPSED> .0</ELAPSED> 
</ROW> 
<ROW> 

(more row information similar to tliat above) 

</ROW> 

(other row blocks) 
</SYSOUT> 
<SYSOUT> 

<SYSOUTJD>XYZ281</SYSOUTJD><SEQ_KEY>XYZ281</SEQ_KEY> 

<JOB>JOB65243</JOB><GEN>3428</GEN> 
<SSEQNO>7823</SSEQNO><ARCDT>01/20/03</ARCDT> 
<ARCTM>12:55:08</ARCTM><PRTDT>00/00/00</PRTDT> 
<LINES> 5373</LINES><PAGES 26</PAGES> 
<BLKS> 21</BLKS><XC0DE> </XCODE> 
<TAPSEQ>4450</TAPSEQ> 

<JOBNAME>XYZ281 </JOBNAME> 

<START>12.38.0</START> 

<ENDED>1 2.44.22</ENDED> 

<ROW> 

(row information like that above> 

</ROW> 

(other row blocks) 

12116.01/4000.12900 22 



</SYSOUT> 

(other sysout blocks) 

</RESULTS> 

These XML documents and docu^n. foments above are only Intended as an 
example. Those skilled in the art may readily concede of how this example may be 
extended to provide the ab«tty to request data, to request commands be executed, and to 
.turn requested data employing XML documents. While XML may be preferred, 
document fbmrats other than XML may be employed to request data, to command actions, 
and to return requested data. In some embodiments some *,m,at other than document 
,bm«t may be employed for communtea«ng requests and commands as well as 
communicating responses. M of these are «,ntemp.ated by this embodiment of the 



ISL 10. 



The ISL 10 described above is read«y extensible to deploy support for new 
retrieval sen,^s 18. All that is needed is that the soflware to access the data and to 
request command execu«on in «,e new system, app.K=a«on, or database be written and 
des^ned to in.er-wori< w«h «,e client se^ice 16 as described above. The administratton 
services c«nponent 26 may be employed to bring the new retrieval sen,lce 18 inU> 
operation on the ISL 10. 

,00651 The ISL 10 described above is intended to provide sendee fe> a broad range of 
citents Who are only consumed by needing io employ the appropriate request 
communicauon sequence and to emptoy the appropriate request document fomnat. 
Turning n<M to F^ure 5, an infom,a«on command layer (iCL) 130 is depk=ted. The ICL 
130 may be a dfent. such as the requestor 14. of the iSL 10. A requestor 132 component 
is dosely coui^ed to a rece^er 134 com^nent. In some embodiments these two 
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components may not be separable but may be one funotional blook. The requestor 132 
sends requests to an ISL 10 to collect data. The requestor 132 sends a r«,uestDocument 
message 66 to the ISL 10 describing the data requested and the forniat in which to 
represent the response. This information is embedded in a request document - also 
referred to as an ISL script - which in some embodiments may be in XML fom,at as 
previously discussed, in some embodin^nts a different response document fbmiat may 
be employed. 

[00661 The receiver 134 receives the response returned by the ISL 10. The receiver 
,^,ves a responselDocument message 104 from the ISL 10 containing a response 
document which contains the data in the fom,at requested. The response document in 
some embodiments may be in XML fomiat as previously discussed. In some 
embodiments a different request document fomiat may be employed. 
,0067] in some embodiments the communication between the ICL 130 and the ISL 10 
may be via a socket «,mmunicatton mechanism. In some embodiments a different 
communication mechanism may be emptoyed. 

100681 The receiver 134 trensfers the data in the response to an ana^^r 136 which 
manipulates the data. The analyzer 136 Uansfe,. the precessed data to a writer 138 which 
fom^ts the processed data, in some embodiments the analyzer 136 and writer 138 may 
not be separable but may be a single functional block. The resultant manipulated and 
fomratled data may be written to a file or may be streamed to a dient of the ICL 130. An 
application programming interface (API) 140 may be prevWed in some embodiments to 
allow extemai agents to invoke the ICL 130 and to receive the preduct of the ISL 10. 
,00691 The analyzer 136 and writer 138 both operate upon the response data according 
to InstnrcUons embedded in a command document ffle which may be referred to as an ICL 
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script. This ICL script may t« formatted in XML fomiat or in some ottier document fomiat. 
The ICL scrip, may be made available to the analyzer 136 and Miter 138 by sending the 
,CL script as an input parameter when invoking the ICL 130 via the AP1 140. ^tema«vely. 
the ICL script may be made available to the analyzer 136 and writer 138 by identi^ng the 
iCL script in the API invocation of the ICL 130. with the ICL script file being located in the 
^1 computer system flte system. A d^erse set of ICL scripts may be loaded info the 
^1 computer file system as pan of Installing «,e ICL 130. The ISL 10 script may be 
stored in the local computer file system, may be provided as an input parameter fo the API 
140, or may be extracted from the ICL script 

100701 The ICL 130 may manipulate, sum. subtract, and combine data received in a 
response document from ^ ISL 10. For example, the ICL 130 may request some billing 
processing data from the ISL 10 with a request document, receive the billing processing 
date from the ISL 10 in a response document, analyze the response document to calculate 
the processing rate of differont billing applications (wireless services billing, consumer tong 
distance bi«ing. commerolal long distance Mling, etc.). and write the billing processing rate 
for each of these services into an output file or roport. The ICL 130 may ^so roceh* its 
input data document from some other souroe. other than ISL 10. that adheres to the ICL 
1 30 input data document format. 

I0«7i, The ICL 130 and its components may execute on a mainframe. wori( staUon. or 
general purpose computer system. General purpose computer systems are discussed in 
moro detail heroinafler. The various components of the ICL 1 30 may execute on the same 
computer or they may execute on different and separate computers. 
10«721 Turning now to Figuro 6 a system 150 for monitoring applications, databases, or 
computer systems is depicted. A monitor 152 is operative to observe or monitor an 
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application 154, for exampie to oMain application 164 related infonnation and staUstics. A 
dashboat) 156 is operative to receive arKi display summary infom«tion from the monitor 
152 on an instrument panel or on a computer screen, pert^aps in association with one or 
more audio speakers. 

100731 The summanr infomiation display may be of the nature to indicate a value in a 
range - such as a numeric display, a bar graph or histogram indication, a meter-type or 
steamy type instn^ment, an audio volume based indication (louder means more or 
less of the indicated value), an audio t«,e based indication (higher pitch means more or 
less of the indicated value), or other such indication - or may be of the nature to indicate 
that a state exists or does not exist - such as a condition light or Idiot-lighf. an alam, light, 
a flashing light, an audio tone, an aud» on^ tone, or other such indication. The monitor 
152 communicates with a trigger 158 which is operative to send an signal, event, or 
message to the dashboanJ when an operational parameter or derived parameter of the 
applicaflon 154 exceeds a defined operational limit The signal sent by the trigger 1 58 may 
cause the dashboard 156 to generate a visual alert cue or an audio alert cue. 
100741 The system 150 for monitoring applications, databases, or computer systems 
and its components may execute on a mainframe, wort, station, or general purpose 
computer system. General purpose computer systems are discussed in more detail 
hereinafter. The various components of the system 150 may execute on the same 
computer or they may execute on different and separate computers. 
l«„5i Tuming now to Figure 7 a capacity management, centralized monitoring, and 
earty waming operations console (CAMEO) 170 is depicted. The CAMEO 170 is a more 
fully featured embodiment of the system 150. The monitor 152 is operative to obsen/e or 
monitor the application 154 through invoking the ICL 130 to produce reports on the 
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application 154. The ICL 130 generates the reports utilizing the functionality of the ISL 10. 
1, is wfthin the scope of the present disclosure that multiple applications 154, not shown, 
may be observed or monitored concunently by CAME0 170. 

[0.761 The monitor 152 is in communication with a reporter 172 which allows the 
parameters obsewed by the monitor 152 to be accessible to the trigger 158, a capacity 
planning 174, a metrics veritotion 176, and an error detection 178. The dashboari 166 is 
operable to control and communicate with the monitor 152, the reporter 172, the trigger 
158, the capacity planning 174, the meWcs verificafon 176, and the enor detectton 178, as 
well as to receive infbmiation. reports, or signals from these components. 
100771 The enor detection 178 is in communication with an enor reports 180 and an 
enor recovery 182. A user Interface (Ul) 184 is operative to display infomratlon and to 
prevlde user control of the CAMEO 170. In some embodln^nts the Ul 184 may be web 
enabled. 

[00781 The trigger 158 may be conf^ured by the Ul 184 to activate or trip or break 
when the parameter of interest exceeds or draps below a threshold value. Some triggere 
158 may be hard coded with static threshold values. When the trigger 158 is acUvated 
some action is taken which may include sending an alert s^nal to the dashboa«l 156 to 
cause an lndicatk», to be presented via the Ul 184 or to interact with an application 154 to 
take corrective action. An exampte of a trigger 158 may be customer Nl generatfon falling 
10 minutes behind schedule. The trigger 158 may serve the purpose. In some 
embodiments, of an eariy warning system so action can be taken to prevent an operational 
failure before the operational faHure or degradation of perfomiance occurs. 
[00791 The trigger 158 may be confi^red by the Ul 184 to latch upon activation. A 
trigger 158 which supports latching funcUon may continue to send an active signal even 
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after the parameter monitored by the trigger 158 returns to a .^rmal value. The latching 
function may be disabled e«her by Ul 184 acl^nowledgement or by passage of a default or 
a configurable length of time. A trigger 158 which supports latching function may confinue 
to send an active signal after acknowledgement or the passage of time when the monitored 
parameter continues to be outside nomial bounds. A trigger 158 which supports latching 
ft,nction which has activated and thereafter been acknowledged may deactivate when the 
monitored parameter returns to nom.al bounds. Some triers 158 may be hard coded to 
support latching function. 

,0080) It IS contemplated that multiple triggers 158 - perhaps many triggers 158 - may 
be deptoyed concurrently in the CAMEO 170 system. A trigger 158 may depend uf«n 
periodic infom^tion updates on the pa.ar,«ter it Is concerned with. Different triggers 158 
may have different periods for lnfom,atk>n update. For example, a trigger 158 which 
acuvates when call detail record (CDR) enors exceed 10% of generated CDRs may be 
scheduled to update its data and analyze the CDR em>r rate on an houriy basis. As 
another example, a trigger 158 which activates when accounts receivable delinquency 
passes a 2% threshoki may be scheduled to update its data and analyze accounts 
receivable delinquency on a daily basis. 

100811 Each different trigger 158 may be associated with an individual ICL 130 script 
and ISL 10 script which extract the infomation monKorad, via the monitor 152, by the 
trigger 158. The monitor 152 may be responsible for scheduling the executton of the 
various trigger 158 scripte at the apprepriate periodic intervals, or this scheduling may be 
embedded In the trigger 158. The reporter 172 may be responsible for distributing 
infomiatlon received by the monitor 152 to the apprepriate triggers 158. In some 
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embodiments the trigger 158 may direcdy invoke the ICL 130 script which returns the 
in*,m,ation the trigger 158 requires, bypassing the monitor 152 and reporier 172 entirely. 
100821 in some embodiments, activation of the trigger 158 may lead to the trigger 158 
conducing a request-iesponse session with the iSU 10 to cause the application 154 to take 
conecUve action including resetting its data and or restarting. 

,0083, The capa* planning 174 of m CAMEO 170 is «>nt,olled by the Ul 184 which 
supports these several capacity planning functtons. Capacity planning 174 may be 
supported by dedicated ICL 130 scripts and ISL 10 scripts which are designed to extract 
*e data or inforniaSon needed to perfom, various capacity planning analyses and 

projections. 

,00841 capacity planning may be employed to detemiine the capacity of present 
resources, current resource utBization. and calculating or otherwise detem,lning future 
resource capacity requirements to avord exhausting the capacity of operatfonal resources, 
such functionality may pemrrt the timely selection and deployment of new resources, and 
may support accurate capital budget planning, or suggest redeployment of existing 
resources to avoid capital expenditures. 

,00851 Capacity planning 174 may pern,* analysis of hypothetk:al business scenarios. 
To support analysis of such scenarkjs. the CAMEO 170 may support feeding a XML data 
file Which captures the data representing the hypotheScai business scenario to the ICL 130. 
in some embodiments the Ul 184 may support creatton of such simulated XML data files to 
be used as input to the ICL 130. In other embodiments such simulated XML data files may 
be created with an editor and spedfred as input to the capacity planning tool via the Ul 184. 
such scenarios may be employed, for example, to detemtine the add«onal capacity 
required to support a new customer Wrth 10,000 subscribers or to analyze the effect of 
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^deploying bill generation computation resources according to a new plan. In some 
embodiments the ICL 130 scripts which support capacity planning 174 may be invoked 
directly by the capacity planning 174 component 

(00861 Metrics veritotion 176 is intended to check operational status. For example, a 
large telecommunications company may have 50 separate billing cycles which it supports 
every month. Completion of a morning bill generation cycle may be required before an 
afternoon billing cycle can begin. If the naming bill generation cyde is delayed, this delay 
has implications for the afternoon billing cycle and perhaps billing cydes of subsequent 
days, it may be valuable to analyze and evaluate the timeliness of each Mling cycle. 
Metrics verification 176 is directed to support such analysis. The infom,ation generated by 
^trics verification 176 may be either a numeric value - minutes behind schedule, piece- 
parts behind quota for time^f-day, percent of target, or other numeric value - or may be a 
passrtail value, for example. The metrics verificatton 174 may support a high level view of 
operations as well as detailed dnll-down views of subcomponents of the operational flow. 
,00871 The em)r detectk,n 178 component is planned to monitor specific operational 
parameters, to generate enor reports 180 when em>rs are discove,«d, to send enor 
informato to the dashboard 156, and In some cases to support error recovery 182 
activities. Dedk:ated ICL 130 and ISL 10 scripts may be employed to provide operatkxral 
infomiatfon. Error detectton 178 may also involve monitoring customer accounts and 
validating account policies for self-consistency when those accounts have been modified. 
,00881 Error recovery 182 may take various fomrs. For example, when one of a series 
of batch jobs on a mainframe computer fails, enor recovery 182 may interi^lpt a series of 
bateh jobs on a mainframe computer whfch must nin successfully end-to-end, restarting 
ttie first failed bateh job, and requeueing or rescheduling the subsequent batch jobs. Em^r 
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^very 182 may cause ISL 10 salpts to execute to command the appropriate 
apiMicatlons. The er«.r recovery 182 may access the ISL 10 through the intermediary of 
the ICL 130, or the e-ror recovery 182 may access the ISL 10 directly (if the error recovery 
182 is designed to act In the capacrty of a requestor 14). 

,00891 In another example, the error recovery 182 may access a list of on^ll 
personnel and invoke an existing enterprise application to send a paging signal to the 
appropriate on^l emi^oyee. In ano«ier exampte, in the case that an account has been 
™dff«d and is in an inconsistent state, the enor recovery 182 may Invoke an e)ds«ng 
enterprise emailing applicaton to send a nottae to the last person to edft the account and 
may invoke an exisUng enterprise PMS to issue a trouble report ticket 
100901 The Infom-atton shared by em>r detectton 178 with the dashboard 156 may 
support bo«, a summary level of detail and a detail drilMown level of detail to provkle enor 
^ery asstetance when enor recovery may not be automated. The Ui 184 may be 
employed to access summary error details and to driMown to lower levels of detalL 
These tower levels of detaH may be st«ed in the CAMEO 170 or they may be freshly 
fonnulated from invoking ICL 130 scripts. For example, ^ a billing application experiences 
a fanure the Ul 1 84 may show that the billing applicatton Is in a failed cond«k>n. By clicking 
on «« billing api^^ation. the Ul 184 may display ^ infom,ation about thte bHllng 
applfcation being montored. «. for example, the billing c^le balanced parameter failed, 
clicking on Ore billing cycle balanced parameter would prompt «,e Ul 184 to display the 
script used to monitor billing cycle balancing, to illustrate where the billing cycle was out of 
balance, and to display the totals associated with this part of the bniing cycle, 
im» corrective acttons taken by error recovery 182 may hook into preexisting 
capaM-rties of the enterprise such as automated email generatfon or automated trouble 
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report generation. The enor detection 178 capability frees personnel from constant 
monitoring of error-free cydes - wt,icl, may constitute the majority of operational qMes - 
since they need only invest time when an actual error has occurred. 
100921 The CAMEO 170 is extensible and may support other operations management, 
reporting, or command functions. The CAMEO 170 may execute on a general purpose 
computer system. General purpose computer systems discussed In more detail 
hereinafter. The various «.mf«nent8 of the CAMEO 170 may execute on the same 
computer or they may execute on different and separate computers. The various 
capabilities of the CAMEO 170 a.« non-intmslve, and they do not require modification of 
existing enterprise applications and do not place a load on those enterprise applicaflons. 
[00931 Figure 8 Is a block diagram illustrating an exemplary Integration of the CAMEO 
170, the ICL 130, and the ISL 10. with the Ul 184 depicted as executing on a desktop 
c„mputer 200. Although the CAMEO 170, the ICL 130, and the ISL 10 may operate as 
independent systems, synergies may be oMained by their combination. HIgWevel 
executives and/or managers of an enterprise may employ this comblnatton employing the 
Ul 184 on the desktop computer 200. As discussed above, the dashboanJ 156 may be 
configured to monitor a variety of system or programs useful for making management 
decisions. The dashboard 156 of the CAMEO 170 may be configured to display 
infon^atlon collected on enterprise statistfcs, such as monitoring the stetus of bUI 
processing. 

[00941 TO facllltete such monitoring, the ISL 10 may monitor the status of applicattons 
that process billing. The bill processing stetlsttes may reside, for example, in the database 
22 and Include records processed, or other real-time infom«tion useful to the manager. 
The crossi>latfom, compatibility and functionality of the ISL 10 described above enables 
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the ISL 10 reWeve such ste«s«cs iro^ *e database 22 wHhout the need to create custom 
applicason to -e^ve. p«..ss and fom, the desired data. The ,CL 130 ope,ab.y requests 
tt,e desi^d data request to the ISL 10, which -etrieves ahd returns the data to the ICL 130, 
substantially as descdbed above. The ICL 130 fonr^U and «tums the data based on the 
for™, desired by the CAMEO 170. In ttiis manner, the CAMEO 170 displays, via the 
dashboari 1 56, the billing statistics for monitoring by the manager on the Ul 184. 
,««51 The dashboam 156 Is operable to display the statistics, reaWme, as the 
infom,a«on « .etrieved, fom«t.ed and returned fn^ the ISL 10 and ICL 130, as desired. 
The present system enables the manager to «mp^ and easBy select other systems of 
interest and Btrieve relevant data quicldy and eff«^ently. The ISL 10 operable to retrieve 
information on otherwtee incompatible system, enaWing a new realm of operation 
management and contnM. Based on the present disclosure, a myriad of Integrated or 
disparate business systems and p^cesses may be eas«y selected and mon«ored by the 
CAMEO 170, employing the ISL 10 and ICL 120. 

100961 The software applications described above - ttie ISL 10, the ICL 130, the system 
150 for monltc^ng api-lcations, databases, or computer systems, and CAME0 170 - may 
be implemented on any genera^purpose a,mputer with suffidtent p«x=essing power, 
memory resources, and M throughput capability to handle the workload placed upon 
it Figure 9 illust^es a typical. gene,«li>urpose computer system suitebie for 
implementing one or more embodiments disclosed herein. The computer system 380 
includes a processor 382 (which may be refen«l to as a central p«)cessor unit or CPU) 
that is in communication witi, memory devices including secondary storage 384. read only 
memory (ROM) 386, random access memory (RAM) 388, Input/output (I/O) 390 devices. 
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and .e^ oonneoBvny devices 392. The processor may be implemented as one or 
more CPU chips. 

[„09„ The secondary sto-^ge 384 is typically comprised of one or more disk drives or 
tape drives and is used for non-voiaUie storage of data and as an over-flow data storage 
device RAM 388 is no. enough to hoki all woridng daU. Secondary storage 384 
n,ay be used to sU,re programs which are loaded into RAM 388 when such programs are 
selected for execution. The ROM 386 is used to store >nst,«c«ons and pertiaps data which 
are read during program executton. ROM 386 Is a nonw^a«le memory de>.ce wh^ 
.ypicaily has a small memory capacity r^a«ve to the larger memory capadty of secondary 
storage. The RAM 388 is used to store volatile data and pertraps to store instructions. 
Access to both ROM 386 and RAM 388 is typically faster than to secondary storage 384. 
10098, 1/0 390 devices may include printers, video monitors, keyboards, mice, track 
bails, vofce recogn^rs. card readers, paper tape readers, or other well-known input 
devices. The networi. connectivity devices 392 may take the fom of modems, modem 
banks, ethemet cards, token ring cards, fiber distributed data interface (FDDl) cards, and 
<*er well-known ne.wori< devices. These networi. connecdv^y 392 dev^ may enable 
tt,e processor 382 to communicate wtth an Internet or one or more intranets. W«h such a 
networic connecuon. K Is contemplated «.3. the processor 382 m^ht receive infom«tion 
,„m the networi,. or might output lnfbm,a.ton to the networi. in the course of perfom,ing the 
above-described me«,od steps. Such infom,a«on. which is often represented as a 
sequence of instmClons to be executed using processor 382. may be received from and 
outputted to the networi<. for example, in the fom, of a computer data s^nal embodied in a 



carrier wave. 
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The pmcessor 382 executes inst^cUons, codes, computer programs, scripts 
it accesses from ha«. disk, floppy dis^ op«cai disk (these various disk based 
systems may ail be considered secondary storage 384), ROM 386, RAM 388, or the 
network connectivity devices 392. 

,00,001 Wh»e several embod»nents have been provided in the present disclosure, ft 
Should be understood that the disclosed systems and methods may be embodied in many 
other spedflc fom,s w«hout depa,«ng from the spirit or scope of the present disclosure. 
The present exempts are to be consWered as illusU^e and not restrictive, and the 
inten«on is not to be limKed to the detaHs gK«n herein, but may be modified within the 
scope of the appended d^ms along wfth their full scope of equK^lents. For example, the 
various elements or components may be combined or integ-^ed In another system or 
certain features may be omitted, or not implemented. 

,00,011 /Uso, techniques, systems, subsystems and methods described and illustrated in 
*e various embodime^ as disc^et or separate may be combined or Integra w»h other 
systems, modules, techniques, or methods without depariing fn>m the scope of the present 
disdk^ure. Other ftems shown as direcUy coupled or communk:a«ng wHh each other may 
be cou^ed through some interface or dev^e, such that the items may no tonger be 
consklered direc«y cou,.ed to each but may s«l, be indi,ec«y coupled and In 
communk^atbn v.*h one another. Other examples of changes, substitu«ons, and 
alteraaons are asceriainable by one skilled in the art and could be made without depar«ng 
from the spirit and scope disclosed herein. 
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